Disable Dilithium and SPHINCS+ sig algs by default #406
Conversation
This fixes open-quantum-safe#399 With the current default enabled sig algs, some servers may fail to complete the TLS handshake. This is probably not an OpenSSL or oqsprovider bug but a buggy TLS implementation on the server side. I guess something similar to what is described in https://tldr.fail/. Until the issue is better understood, let's enable less sig algs by default so that the changes of users being affected by this issue are lower. The only file manually edited was oqs-template/generate.yml with ```shell sed -i -e 's/enable: true/enable: false/g' oqs-template/generate.yml sed -i -e '552,660s/enable: false/enable: true/g' oqs-template/generate.yml sed -i -e '661,763s/enable: false/enable: true/g' oqs-template/generate.yml ``` The rest of the files were generated with ```shell bash oqs-template/generate.sh ``` Signed-off-by: Iyán Méndez Veiga <[email protected]>
iyanmv
force-pushed
the
enable-less-sig-algs
branch
from
33f0ba2
to
4177d6e
Compare
There was a problem hiding this comment.
Thanks for this analysis and proposal! How many sigalgs do these " buggy servers" support OK? Can we refer to a (TLS) spec doc that confirms this as truly buggy? If so, let's try to find out those servers' software and raise an issue; completely disabling by default two complete PQ sigalg families seems too strong a limitation for oqsprovider users in response. If oqsprovider in turn violates a spec (sending too many code points?) such a limitation may be called for; but I'd suggest doing a poll first what should be removed from the default set. Finally, the generate.py code generator must run with idempotence (this property is checked by CI and must be assured before merge).
|
I'm not sure it's worth disable Dilithium as for now - it may be used by some existing installations and it's worth having an option to test the compatibility |
These particular two servers (
I don't think there is such TLS spec limiting the number of sig algs in the Client hello message, but I will double check. I can also create an issue in fwupd repo, author is very responsive and maybe he can give some hints about why the server fails to respond correctly.
I tried to achieve this by using the |
This fixes #399
With the current default enabled sig algs, some servers may fail to complete the TLS handshake. This is probably not an OpenSSL or oqsprovider bug but a buggy TLS implementation on the server side. I guess something similar to what is described in https://tldr.fail/.
Until the issue is better understood, let's enable less sig algs by default so that the chances of users being affected by this issue are lower.
The only file manually edited was oqs-template/generate.yml with
The rest of the files were generated with